Local area networks (LAN) and wide area networks (WAN) have become ubiquitous. Such networks link computers and other resources together in a network, in which network protocols are used to enable computers and other resources to communicate with each other over the network, such as to exchange data. Often, a private network, such as a LAN, WAN, or other private network is interconnected with other networks, such as the Internet or other private or public networks.
In the case of a private LAN, WAN, or other network connected to a public network such as the Internet, security measures are often put in place to prevent unauthorized users from accessing protected resources on the LAN, WAN, or other network. For example, a LAN or WAN may include one or more application servers used to provide access to application functionality from a server on the network. In many cases, measures are taken to limit access to such applications, so that members of the public will not gain unauthorized access to the applications via the public network.
To use an application, a user typically uses a client system to access the application server via the network by invoking client software associated with the application. The client software establishes a connection to the application server via the network and exchanges requests and responsive data via the network as necessary to perform the tasks desired by the user. Such applications may include file access; data management and storage; electronic mail and other communication applications; supply chain management, human resources, accounting, contact management, and other business applications; etc.
In some cases, the enterprise or entity associated with the LAN or other private network determines it would be advantageous or convenient to allow authorized users to access via the public network, such as the Internet, applications residing on servers or other computers on the private network. One approach that has been used to provide such access is the so-called virtual private network (VPN) approach. FIG. 1A shows a typical virtual private network configuration 100 in which a remote client 102 is configured to connect via a public network 104, such as the Internet, with a virtual private network (VPN) server 106. VPN client software 108 installed on the remote client 102 is invoked to enable the remote client 102 to connect with the private network 110 associated with the VPN server 106, effectively allowing the remote client 102 to access applications and services on the private network 110 as if it were a virtual client 112 on the private network. Once so connected, the remote client 102 may access applications on the private network, such as one or more of the plurality of network applications 114, as if it were a client on the private network 110. While four applications are shown in FIG. 1A, more or fewer applications may be present on private network 110.
The VPN approach has certain disadvantages, however. For instance, it is necessary to install and configure client side VPN software on each client system that the administrators of the private network wish to be able to connect remotely to the private network via the VPN server. In some cases, software from a plurality of vendors must be installed on a single system in order to enable a client system to connect to the private network via the VPN server. The ongoing costs of administration can be high as well, as small changes in the applications on the network may require updating and/or re-configuration of all of the clients to which access via the VPN server is provided. In addition, in many cases a single enterprise may comprise more than one private network, linked together in a LAN or WAN, which makes it even more difficult to implement the VPN model of remote access. Also, use of encryption for security may be difficult using the VPN model. Finally, under the VPN approach the remote user is fully regarded as a node on the private network, which may present a security risk for the private network if the remote system has been compromised by an unauthorized user or software, such as a virus.
Another approach that has been used to provide controlled access to applications residing on servers or other computers on a private network is the so-called “extranet in a box” approach. FIG. 1B shows one typical “extranet in a box” configuration 150. A remote client 152 connects via a public network 154, such as the Internet, with a remote access server 156 associated with a private network 158. Applications 160a, 160b, 160c, and 160d reside on one or more application servers connected to the private network 158. In order to enable a user of the remote client 152 to access one or more of the applications 160a, 160b, 160c, and 160d, special software modules 162a, 162b, 162c, and 162d, respectively, must be written and installed on the remote access server 156. Each software module is specific to a corresponding application (e.g., software module 162a may correspond to application 160a), and is custom written to enable a remote user, such as a user of remote client 152, to access the application for which it is written by using web browser software installed at the remote client 152 to communicate with the remote access server 156 using the hypertext transfer protocol (HTTP). Using this approach, the browser is used to run at the remote client 152 a web-based version of each respective application. This approach does not require the installation of client side VPN or other special software at the remote client 152, as the already-installed browser software is used. However, the features available via a browser-run version typically will be limited, especially when compared to the full capability of the native client application software that would be used to access the application from a client on the private network. One example of such a limitation is the difference between using a full function electronic mail program installed on a client system, such as Microsoft Outlook™, and using a web-based electronic mail service accessed using browser software, such as Microsoft Hotmail™. In addition, this approach requires a lot of customization of the remote access server at the application layer, which in some cases may make it expensive and time consuming to implement, e.g., in environments in which a large number of legacy applications may be present or in which new or updated applications are installed over time.
Therefore, there is a need for a way to provide access via a public network to applications residing on a private network that is secure; does not require special client side software or configuration; is capable of providing access to all applications to which providing such access is desired, including legacy applications, without requiring that custom code be created for each such application; and that allows the remote user to use the native capabilities of the installed client side application software.